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Abstract.  Safety  and  secrecy  are  formulated  for  a  deterministic  pro¬ 
gramming  language.  A  safety  property  is  defined  as  a  set  of  program 
traces  and  secrecy  is  defined  as  a  binary  relation  on  traces,  character¬ 
izing  a  form  of  Noninterference.  Safety  properties  may  have  sound  and 
complete  execution  monitors  whereas  secrecy  has  no  such  monitor. 


1  Introduction 

It  is  often  argued  that  information  flow  is  not  safety.  One  argument  is  refine¬ 
ment  based  and  originates  with  Gray  and  McLean  [5].  They  observed  that  for 
nondeterministic  systems,  a  class  of  information  flow  properties,  namely  the 
Possibilistic  Noninterference  properties,  are  not  safety  properties.  The  reason  is 
because  they  are  not  preserved  under  replacement  of  nondeterminism  in  a  sys¬ 
tem  with  determinism.  An  example  is  an  implementation  of  nondeterministic 
scheduling  using  a  round-robin  time-sliced  scheduler  [8] .  A  possibilistic  property 
basically  asserts  that  certain  system  inputs  do  not  interfere  with  the  possibility 
of  certain  events.  So  nondeterminism  is  essential  to  such  properties.  A  safety 
property,  on  the  other  hand,  is  insensitive  to  this  kind  of  refinement.  Another 
argument  commonly  heard  is  that  information  flow  is  a  predicate  of  trace  sets 
whereas  safety  is  a  predicate  of  individual  traces.  This  argument  can  be  applied 
to  deterministic  systems.  We  examine  it  more  carefully  and  present  a  secrecy 
criterion  for  programs  that  relates  secrecy  and  safety. 

2  A  characterization  of  safety  properties 

Consider  a  deterministic  programming  language  with  variables: 

{exp)  e  ::=  x  \  n  \  e\  +  e2  |  e\  —  e2  |  e\  =  e2 
( cmd )  c  ::=  x  :=  e  \  C\\c-2  |  if  e  then  c\  else  Co  |  while  e  do  c 
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Here  x  stands  for  a  variable  and  n  for  an  integer  literal.  Integers  are  the  only 
values;  we  use  0  for  false  and  nonzero  for  true.  Note  that  expressions  do  not  have 
side  effects,  nor  do  they  contain  partial  operations  like  division. 

A  transition  semantics  is  given  for  the  language  in  Fig.  1.  We  assume  that 
expressions  are  evaluated  atomically.  Thus  we  simply  extend  a  memory  p,  in  the 
obvious  way  to  map  expressions  to  integers,  writing  p(e)  to  denote  the  value  of 
expression  e  in  memory  //. 


(update) 


(sequence) 


(branch) 


x  E  dom(p) 

{x  :=  f,  /I )  — >  p[x  :=  11(e)] 

(ci,p)  — >■  [i _ 

(ci;c2,/i)  — >  (c2 , \i  ) 

(ci,p)  — >■  (c'\ ,  [1  ) 

(ci;c2,p)  — >  (c', 

Me)  +  0 _ 

(if  e  then  ci  else  c2,/u)  — >  (ci,/x) 


Mg)  =  0 _ 

(if  e  then  ci  else  C2,//)  — >  (c2,/u) 


(loop)  p(e)  =  0 

(while  e  do  c,  p)  — ►  fi 


Me)  ^  0 _ 

(while  e  do  c,  p)  — >  (c;  while  e  do  c,p) 


Fig.  1.  Transition  semantics 


The  rules  define  a  transition  relation  — >-  on  configurations.  A  configuration 
m  is  either  a  pair  (c,fi),  where  c  is  a  command  and  fi,  is  a  memory,  or  simply 
a  memory  \i.  We  define  the  reflexive  transitive  closure  — in  the  usual  way. 
First  m  — m,  for  any  configuration  m,  and  m  — >k  m" ,  for  k  >  0,  if  there  is 
a  configuration  m'  such  that  m  — i-^-1  m'  and  m'  — »  to".  Then  to  — >*  m'  if 
to  — >k  to'  for  some  k  >  0. 

A  trace  is  a  (possibly  infinite)  derivation  sequence  toi  — ^  too  — >  ■  ■  ■  with 
finite  prefixes  toi  — >  too,  m\  — >  m?  — >  m3,  and  so  on.  And  if  a  is  a  trace 
then  so  is  every  prefix  of  a. 

Definition  1.  A  safety  property  is  a  set  S  of  traces  such  that  for  all  traces  a, 
a  is  in  S  iff  every  finite  prefix  of  a  is  in  S.  A  program  is  safe  if  every  trace  of  it 
belongs  to  S . 

The  “only-if”  direction  guarantees  S  is  prefix  closed,  and  the  “if”  direction  allows 
us  to  reject  an  infinite  trace  by  examining  only  a  finite  amount  of  it.  If  there  is 
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an  infinite  trace  that  is  not  in  5,  then  it  must  have  a  finite  prefix  that  is  also 
not  in  S.  Hence  safety  cannot  rule  out  behaviors  that  amount  to  reaching  some 
execution  state  infinitely  often. 

We  also  assume  that  the  set  of  all  finite  traces  in  S  is  recursive.  Although 
this  need  not  be  true  of  a  safety  property,  it  seems  reasonable  given  that  one 
typically  identifies  a  safety  property  with  the  ability  to  enforce  it  at  runtime  by 
examining  program  traces  of  finite  length. 

3  A  characterization  of  secrecy 

We  want  to  talk  about  secrecy  in  programs  of  our  deterministic  language  so  how 
should  secrets  be  introduced?  Well  there  is  nothing  intrinsically  secret  about  any 
integer  so  we  should  forget  about  associating  secrecy  with  values.  Instead,  we 
associate  secrecy  with  the  origin  of  a  value  which  in  our  case  will  be  the  free 
variables  of  a  program.  So  each  variable  is  either  high  (secret)  or  low  (public). 
The  idea  is  that  any  initial  value  of  a  high  variable  is  assumed  to  be  secret 
merely  by  virtue  of  being  stored  in  a  high  variable.  The  initial  value  of  a  low 
variable  is  not  secret. 

This  origin-view  of  secrecy  differs  from  the  view  held  by  others  working  with 
assorted  lambda  calculi  and  type  systems  for  secrecy  [1,3].  There,  secrecy  is  as¬ 
sociated  with  values  like  boolean  constants.  It  does  not  seem  sensible  to  attribute 
any  level  of  security  to  such  constants.  After  all,  what  exactly  is  a  “high-security” 
boolean?  Semantically,  there  is  nothing  that  makes  it  high  or  low.  Basic  constants 
can  be  treated  as  high  or  low,  and  therefore  we  take  the  view  that  they  should  be 
typed  polymorphically  in  any  type  system  where  levels  of  classification  become 
(partially  ordered)  types. 

We  need  to  talk  about  secrecy  violations.  But  what  constitutes  a  violation? 
Suppose  A;  is  a  low  variable  and  h  is  a  high  variable  with  initial  value  17.  Is 
the  assignment  k  :=  17  in  violation  of  secrecy?  Presumably  not  since  it  just  got 
lucky  and  does  not  reliably  reveal  the  value  of  h  as  h  varies.  On  the  other  hand, 
k  :=  h  would  be  a  violation. 

As  another  example,  consider 

k  :=  h;  k  :=  k  —  h 

Does  it  exhibit  a  violation?  Despite  the  first  assignment,  we  might  still  regard 
the  composition  as  secure  since  h  is  only  temporarily  stored  in  k  which  always 
has  final  value  zero.  One  might  wonder  though  whether  even  temporary  storage 
is  a  violation.  It  would  be  if  execution  could  be  suspended  for  some  reason,  say 
in  an  interleaved  execution  environment,  and  k’s  contents  inspected.  For  now, 
we  shall  stay  with  deterministic  sequential  programs  and  focus  on  what  they  are 
capable  of  doing  upon  normal  termination.  In  this  case,  the  composition  would 
be  secure.  This  also  allows  us  to  say  that 

h  :=  k;  k  :=  h 
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too  is  secure  since  there  is  no  way  to  update  h  between  the  assignments. 

One  can  begin  to  see  the  subtlety  in  deciding  what  constitutes  a  secrecy  vio¬ 
lation.  In  the  end,  it  comes  down  to  what  is  observable  by  users  and  programs. 
Users  can  make  external  observations  of  running  programs  and  system  behav¬ 
ior  on  chosen  inputs  in  order  to  learn  secrets.  Running  time,  resource  usage, 
exceptions  and  so  on  are  all  valuable  sources  of  information,  provided  by  even 
well-designed  programs,  that  can  be  observed  outside  a  program  and  exploited. 
Programs,  in  contrast,  make  internal  observations  in  that  they  are  limited  to 
whatever  observations  their  semantics  prescribe.  Controlling  these  observations 
is  much  more  tractable  as  long  as  implementations  are  faithful  to  the  semantics1 
and  any  program  translation  preserves  the  secrecy  criterion  of  interest.  With 
a  semantics  at  least,  we  have  a  means  of  specifying  and  reasoning  about  the 
behaviors  of  programs  and  the  observations  they  can  make.  We  shall  concern 
ourselves  with  internal  observations  only.  This  is  still  useful.  For  instance,  it 
treats  a  Trojan  Horse  in  mobile  code  that  attempts  to  leak  client  secrets. 

So  now  that  we  have  some  intuition  behind  secrecy,  how  do  we  formalize  it? 
There  are  a  number  of  different  techniques  such  as  process  calculi  equivalence 
[2],  a  PER  model  [6],  and  operational  formulations  [8-10].  In  order  to  contrast 
secrecy  with  safety,  we  give  a  trace-based  description.  It  is  useful  to  first  define 
a  notion  of  configuration  equivalence.  Memories  p  and  p!  are  equivalent,  written 
p  ~  p' ,  if  p(v)  =  p'{v)  for  all  low  variables  v.  And  (c,/x)  ~  (c\p!)  if  c  and  c'  are 
syntactically  equal  and  p  ~  p! . 

Definition  2.  Secrecy  is  a  binary  relation  R  on  traces  where  R(<j,<j')  is  true 
unless  a  has  the  form  ni\  — t  m 2  — >•  •  •  •  — »•  p,  a'  has  the  form  m[  — »• 
m'2  — >  ■  ■  ■  — t  p' ,  mi  ~  ni[  and  fj,  p' .  A  program  is  secret  if  R  relates  every 
pair  of  its  traces. 

Basically,  secrecy  is  asserting  that  the  final  value  of  any  low  variable  does  not 
depend  on  the  initial  values  of  high  variables.  This  definition  applies  only  to 
deterministic  programs.  Notice  that  a  program  may  be  secret  even  though  it  has 
a  finite  trace  and  an  infinite  trace  whose  starting  configurations  are  equivalent. 
In  other  words,  termination  of  a  secret  program  can  be  affected  by  differences 
in  the  initial  values  of  high  variables. 

4  Contrasting  secrecy  with  safety 

Notice  that  secrecy  relates  program  executions  whereas  a  safety  property  does 
not.  This  is  the  essential  difference  between  them.  There  are  some  interesting 
consequences  of  this  difference  in  terms  of  enforcing  secrecy  versus  safety. 

Suppose  we  take  the  view  that  a  program  may  be  unsafe  but  we  won’t  worry 
about  its  offending  traces  unless  one  of  them  tries  to  emerge  during  the  current 
execution.  So  we  don’t  try  to  convince  ourselves  once  and  for  all  that  a  program 
is  safe.  Instead  we  accept  the  fact  it  may  be  unsafe  and  put  our  trust  in  an 

1  Knowing  when  an  implementation  is  faithful  can  also  be  tricky. 
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execution  monitor  to  guard  against  unsafe  behavior.  This  is  an  old  idea  from 
operating  systems.  A  monitor  works  by  monitoring  the  execution  of  a  program 
and  trapping  it  before  it  violates  the  policy  being  enforced  [7].  It  relies  only  on 
information  available  at  runtime  and  does  not  examine  the  entire  program  being 
executed.  Recovery  from  such  traps  may  be  possible  in  some  applications.  It  is 
in  these  applications  that  monitoring  is  appealing  because  the  complement  of 
deciding  whether  a  program  is  safe  (call  it  unsafetv)  may  be  r.e.  when  safety  is 
not.  When  safety  is  not  r.e.,  we  are  immediately  faced  with  incompleteness  in 
any  sound  and  r.e.  logic  for  analyzing  it.  If  the  logic  were  complete  then  safety 
would  be  r.e.  since  we  would  have  a  way  to  accept  safe  programs:  simply  hand 
the  given  program  off  to  the  machine  M  accepting  programs  that  have  proofs  in 
the  logic.  If  M  accepts  then  we  accept  and  we  know  we’re  correct  because  the 
logic  is  sound.  And  if  the  program  is  safe,  then,  by  completeness,  it  has  a  proof 
and  therefore  M  will  accept  it.  Incompleteness  can  be  an  obstacle  in  practice, 
depending  on  the  logic.  Execution  monitoring  avoids  it. 

Monitoring  can  also  dovetail  nicely  with  a  machine  M  accepting  unsafety.  M 
might  cycle  through  all  memories  (suitably  encoded)  and  run  a  given  program 
on  each  of  them  for  at  most  some  fixed  number  of  steps,  where  the  memories 
and  number  of  steps  are  governed  by  pair  generation.  If  the  unsafe  behavior 
reveals  itself  within  the  number  of  steps  allowed  (guaranteed  to  be  detectable 
by  M  since  the  finite  traces  of  a  safety  property  form  a  recursive  set),  then  M 
accepts.  An  execution  monitor  for  unsafety  is  essentially  a  lazy  version  of  M. 
Eventually  the  monitor  might  decide  that  a  given  program  is  unsafe  but  that 
does  not  concern  us  unless  the  current  run  demonstrates  it. 

We  need  to  be  clear  on  the  terms  soundness  and  completeness.  The  monitor 
is  a  lazy  version  of  M  which  accepts  unsafety.  Since  M  accepts  unsafety,  we 
have  that  if  a  program  is  unsafe  then  M  will  say  so  (completeness)  and  if  M 
says  a  program  is  unsafe,  it  is  indeed  unsafe  (soundness).  Therefore,  if  M  never 
says  a  program  is  unsafe  then  the  program  is  safe.  This  we  take  as  a  soundness 
criterion  for  M  (and  the  monitor)  with  respect  to  the  safety  property  at  hand. 
Likewise,  if  a  program  is  safe,  then  M  never  says  otherwise.  And  this  we  take  as 
a  completeness  criterion  for  M  relative  to  safety. 

A  similar  technique  can  be  used  to  prove  that  the  complement  of  deciding 
whether  a  program  is  secret  is  r.e..  One  can  encode  a  pair  of  memories  and  adopt 
some  convention  for  determining  values  of  low  variables,  and  then  run  the  given 
program  for  at  most  a  fixed  number  of  steps  on  each  memory  in  a  generated  pair 
when  the  memories  are  equivalent.  If  the  runs  terminate  yielding  inequivalent 
memories,  then  accept.  But  unlike  the  complement  of  safety,  the  technique  here 
does  not  dovetail  with  execution  monitoring  because  it  requires  two  memories. 
Monitoring  involves  only  one,  that  of  the  current  execution.  So  for  this  notion 
of  secrecy,  monitoring  cannot  be  employed  as  a  way  to  guard  against  secrecy 
violations  as  it  was  used  to  guard  against  safety  violations.  In  fact,  we  can  be 
more  rigorous.  As  we  shall  see,  one  can  prove  there  is  no  policy,  implemented  by 
an  execution  monitor,  that  implies  secrecy  and  is  complete.  In  contrast,  there 
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are  many  safety  properties  that  have  sound  and  complete  execution  monitors. 
So  what  alternatives  are  there  for  enforcing  secrecy? 

One  approach  is  to  turn  to  a  static  analysis  whereby  we  attempt  to  show 
once  and  for  all  that  a  given  program  is  secret.  But  we  will  be  faced  with  in¬ 
completeness  in  any  sound  and  r.e.  system  for  reasoning  about  secrecy  because 
determining  whether  a  program  is  secret  is  undecidable.  Decidable  type  sys¬ 
tems  fall  into  this  category  [10].  Instead,  one  may  adopt  a  very  expressive  logic 
and  use  verification  conditions  for  establishing  secrecy  without  worrying  about 
mechanizing  proofs.  Work  along  these  lines  is  described  in  [4], 

In  the  next  section,  we  shall  see  an  example  of  a  program  secrecy  crite¬ 
rion  implied  by  a  policy  that  is  implemented  using  an  execution  monitor.  It  is 
called  weak  secrecy.  A  disadvantage  of  weak  secrecy  is  that  it  ignores  indirect 
dependencies  caused  by  branching — hence  the  term  “weak”.  As  a  result,  some 
programs  satisfy  weak  secrecy  but  are  not  secret.  But  there  are  also  secrect  pro¬ 
grams  that  do  not  satisfy  weak  secrecy,  reflecting  a  basic  requirement  of  safety. 
So  neither  property  implies  the  other.  The  monitor  is  sound  but  incomplete  for 
weak  secrecy.  It  may  trap  a  program  that  satisfies  weak  secrecy. 

5  Weak  secrecy 

Every  trace  has  a  corresponding  branch-free  program  formed  by  sequencing  up¬ 
dates  from  those  steps  of  the  trace  whose  derivations  are  rooted  with  updates. 
For  instance,  if  k,  h  €  and  y i(h )  =  0,  then  corresponding  to  the  trace 

(k  :=  h ;  if  h  then  k  :=  1  else  k  :  =  0,  fj)  (m i) 

— )•  (if  h  then  k  :  =  1  else  k  :=  0,  /j[k  :=  /j(h)])  (mo) 

— ■>  ( k  :=  0,  /j[k  :=  n{h)])  (m3) 

— )•  n\k  :=  n(h)][k  :=  0]  (m 4) 

is  the  branch-free  program  k  :=  h\  k  :=  0.  Notice  that  by  rules  (loop)  and 
(branch),  the  corresponding  program  for  a  trace  may  be  empty. 

Now  we  say  that  a  program  is  weakly  secret  if  every  trace  of  it  has  a  secret 
branch-free  program.  For  instance,  the  program  in  the  preceding  example  is  not 
weakly  secret.  Traces  m\  — >  mo  and  m\  — >  mo  — y  m3  do  not  have  secret 

branch-free  programs,  but  m\  — >  mo  — y  m3  — ^  nq  does.  It  may  seem  that 

we  still  have  not  defined  a  criterion  for  program  secrecy  that  follows  from  some 
policy  implemented  by  execution  monitoring  since  we  still  cast  our  definition  in 
terms  of  secrecy  which  relates  program  executions.  But  there  is  a  policy  that 
implies  weak  secrecy  and  it  can  be  implemented  by  an  execution  monitor. 

5.1  A  policy  for  weak  secrecy  and  its  monitor 

An  execution  monitor  is  given  in  Fig.  2  as  a  set  of  rules  governing  transitions 
that  the  monitor  can  make.  Each  transition  has  the  form 

(c,  — >  m,  q 
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where  q  and  q'  are  states  {k}  or  {k,  h).  The  monitor  is  equipped  to  handle 
executions  of  programs  with  only  two  variables,  namely  k  and  h,  which  are  low 
and  high  variables  respectively.  A  state  indicates  those  variables  whose  values 
at  that  point  are  independent  of  initial  values  of  h.  This  of  course  may  change 
during  execution  depending  upon  updates  to  h. 

The  policy  is  captured  by  the  (update)  rules.  If  we  take  state  {&}  to  be  the 
initial  state,  then  the  third  (update)  rule,  for  instance,  allows  a  transition  to 
state  {k,  h}  because  h  is  the  target  of  the  assignment  and  h  does  not  occur  in  the 
right  side  e.  Thereafter,  h  is  treated  as  a  low  variable  in  state  {k,  h).  Notice  that 


(update)  k  G  dom(ii),  h  e 

(k  :  =  e,/i),  {k}  -A  fi[k  :=  fi{e)],{k} 

h  G  dom(p),  h  G  e 

(h  :=  e,fi),{k}  A  fi[h  :=  fi{e)],{k} 

h  G  dom(n ),  h  e 

(h  :=  e,fi),{k}  A  fi[h  :=  /<(e)],  {k,h} 

x  G  dom(/i) 


(x  :=  e,/j,),{k,h}  A  /i[x  :=  /x(e)],  {k,  h} 
(SEQUENCE)  {ci,n),q  A  fi\q' _ 


(ci;c2,/f),g  A  (. C3,fj!),q 1 

{ei ,/i),q  A  ( c'un '),q' 

(branch) 

(ci;  Ci,  ii),q  (c'i;c2  ,M  A 

Me)  4  0 

(if  e  then  ci  else  C2,fi),q  — A 

p(e)  =  0 

(ci,p),g 

(if  e  then  ci  else  C2,li),q  — — > 

(C2,M,9 

(loop) 

II 

o 

(while  e  do  c,/x),q  -A-  qi,q 


Me)  4  0 _ _ 

(while  e  do  c,/i),q  — — >  (c;  while  e  do  c,fi),q 


Fig.  2.  An  execution  monitor 


once  an  evaluation  reaches  state  {k,h},  it  remains  in  {k,h}  thereafter.  In  state 
{k,h},  the  monitor  no  longer  has  any  effect  on  executions.  This  is  where  the 
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semantics  of  Fig.  1  and  the  monitor  merge  in  the  sense  that  for  every  command 
c,  (c,  /j)  — >  m  if  and  only  if  (c,  fj) ,  {k ,  h}  m,{k,h}. 

Remark  1.  One  can  think  of  the  states  in  a  transition  as  inherited  and  synthe¬ 
sized  attributes.  Generalizing  the  execution  monitor  to  handle  more  variables 
can  be  done  by  introducing  a  set  I  of  variables,  each  of  whose  value  is  in¬ 
dependent  of  the  initial  value  of  any  high  variable.  There  would  actually  be 
only  two  (update)  rules.  The  first  rule’s  hypothesis  would,  for  an  assignment 
x  :=  e,  require  V/i  €  high,  h  €  I  V  h  £  e,  Its  synthesized  attribute  would  be 
I U  {:c}.  The  second  rule’s  hypothesis  would  require  that  x  is  a  high  variable  and 
3 h  6  high,  h  0  /  A  h  G  e.  Its  synthesized  attribute  would  be  simply  I. 

We  can  regard  a  set  of  traces  of  the  monitor  as  a  safety  property  related  to 
secrecy  by  the  following  theorem: 

Theorem  1.  Let  a  be  a  trace  of  the  monitor  starting  in  state  { k }.  Then  every 
finite  prefix  of  a  has  a  secret  branch-free  program. 

If  the  monitor  never  traps  a  given  program  on  any  input,  when  started  in 
state  { k },  then  the  program  is  weakly  secret.  However,  a  program  may  be  weakly 
secret  yet  get  trapped  (e.g.  k  :=  h  —  h).  The  monitor  also  traps  a  secret  program: 

k  :=  h;  k  :=  k  —  h 

Here  there  is  a  trace  whose  branch-free  program  is  just  k  :=  h  which  is  not  secret. 
One  might  consider  altering  the  monitor  in  some  way  to  admit  all  executions  of 
this  program  but  then  its  traces  would  no  longer  be  prefix  closed  as  a  trace  for 
k  :=  h  would  not  exist  if  the  monitor’s  policy  implies  secrecy.  It  follows  then  that 
there  is  no  monitor-enforced  policy  that  is  sound  and  complete  for  secrecy  since 
the  set  of  all  traces  of  every  monitor  is  prefix  closed.  Simply  put,  if  the  monitor 
executes  k  :=  h,  then  it’s  unsound,  and  if  it  doesn’t,  then  it’s  incomplete. 

The  monitor  also  ignores  indirect  dependencies.  For  instance,  it  does  not  trap 

if  h  then  k  :=  1  else  k  :=  0 

even  though  the  program  is  not  secret. 

6  Concluding  remarks 

Execution  monitoring  has  been  a  useful  mechanism  for  implementing  various 
policies.  It  is  important  to  distinguish  policies  from  properties.  A  policy  implies 
a  property,  and  in  some  cases,  may  be  more  restrictive  than  it  needs  to  be  in 
order  to  imply  the  property.  The  execution  monitor  presented  here  implements 
a  policy  that  implies  weak  secrecy  in  the  sense  that  if  it  never  traps  a  given 
program  on  any  input,  when  started  in  state  {k},  then  the  program  is  weakly 
secret.  It  does  not  however  imply  secrecy.  In  fact,  no  policy  implemented  by  an 
execution  monitor  can  imply  secrecy  and  be  complete. 


An  interesting  direction  to  pursue  is  completeness  of  the  monitor  for  weak 
secrecy,  that  is,  trying  to  extend  the  monitor  so  that  it  never  traps  a  weakly  secret 
program.  Doing  this  for  a  more  realistic  set  of  expressions  would  be  challenging. 
We  assumed  that  expressions  are  executed  atomically  and  that  the  monitor  can 
inspect  an  expression  at  runtime.  But  expressions  obviously  can  be  far  more 
complex,  involving  function  calls,  conditional  expressions,  exceptions  and  side 
effects.  One  cannot  assume  these  sorts  of  expressions  execute  atomically. 
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